Re: [-empyre-] intro

[Henry Warwick <henry.warwick@sbcglobal.net>]

I have a few thoughts on this:

First, warm greetings to: adam@xs4all.nl.

Second, Adam asked:

> Perhaps fundamental to the topic is how we
> categorise the phenomenon of
> audio and video data delivered over tcp/ip. Does
> streaming belong within
> the web or do we understand that it inhabits the
> wider technical arena of
> the internet?

The "web" and the "internet" are both constructs which
share some fundamental technologies, such as the
TCP/IP collection of packet switching communication
protocols. This is their strength and their weakness.

IP technology is based on packet exchange and the
handling of said packets. The reasons for this are,
IMHO, a bit complex, but it boils down to a need for
"making sure it all gets there" combined with "we have
to send a gallon of information in shotglass portions
through a straw - and it's one of those 'skinny red
ones that you get in a drink with umbrellas and fruit'
type of straw - not one of those 'big fat ones you get
with a Megaportion Slurpy down at 7-11' type of
straws..."

When the "internet" was first developed by your
friendly neighbourhood militarists back in the days of
IBM 360s and 370s and the soundtrack back then
featured the likes of Jimi Hendrix and Carole King,
the "internet" was mostly experimental, where the
basic ideas of packet queuing and switching were
worked out, enabling a primitive form of email. It
didn't use TCP/IP, it used NCP, until (I think) 1983
or 84. Anyway, a big boost was when the National
Science Foundation jumped in and got universities
online with their net in 1986 or so. shortly
thereafter was when I got involved with the "internet"
in the form of BBSs on fidonet, bitnet, etc. Just
uploading a simple message to a BBS was often a
painful exercise in patience.

Adam then notes:

> This is interesting to me because the 'web' seems to
> be a rather hostile
> environment for streaming.

It's not the "web" that's the problem, it's a few
things (yay! now we get to the meat of the story...)
that are based on what I noted above:

1. packets, i.e., IP
2. the straw, aka bandwidth restraints

As long as a everything is transmitted in packets and
each packet has to be numbered, noted, delivered,
spoken for, and requested; and each packet has to be
crammed through a delivery system of questionable
strength and reliability, streaming is going to be a
problem. Period.

There is no true "broadcasting" in a radio sense,
because of these technical constraints. These
constraints were imposed for Very Good Reasons (to
insure data integrity).

Example inverse: right now in SF there's a pirate
radio station at 87.9 FM. All they play is early 80s
late 70s Goth/Punk/New Wave stuff - Siouxsie and the
Banshees, Joy Division, Gang of 4, Bauhuas, Xray Spex,
etc. I tune it in on my car (a 91 toyota Corolla) on
its ancient and feeble analogue radio, but my wife's
spiffy Audi A4 and its more finicky digital tuner
*doesn't pick it up*. The signal isn't consistent
enough for the digitally "enhanced" tuner to lock on -
sort of like a webpage that comes up 404.

The web streams "signals" but these are in packets and
if it drops packets, the signal drops out, and you
could lose connexion between the digital "broadcaster"
and the digital "reciever". This is a HUGE problem
with HDTV right now and demonstrates the wisdom of the
European protocol (short words over greater frequency
bandwidth - better reception for fewer channels)
versus the American method (longer words over narrower
frequency bandwidth - shakier reception but LOTS more
channels) and while that is a battle for another day,
it is indicative of the kinds of problems the
"internet" such as it is, is presently forced to deal
with and will become an increasingly dire situation in
the future, given its dependence on IP. 

The only thing that will change this is to scrap IP
and packets and (somehow) get to a direct superhigh
frequency "channelling" protocol that permits millions
if not billions of channels all of it streaming at
once or on instant demand. How such a system would
work, I have no idea, but logically in order to insure
interactivity it would require each reciever to be a
broadcaster - to eliminate the heirarchy of
Host/Client. Otherwise, you need a "manager" which
will have to handle the data and insure its
transmission and then you're back to packets and IP.
Also the health effects of such a system blasting that
much radiation through wireless networks - well -
it'll keep the pigeon population down...

Also, given how corporations and their property
enforcement divisions (aka governments) operate, the
political possibilities of such a system run down
toward zero. And given that uncompressed HDTV at 60
fields per second runs around 130 megabytes PER
SECOND, and then thinking how you'd have to multiplex
and multiply that by a few dozen orders of magnitude,
the technical feasibility of such a system also runs
towards zero, AND given the huge investment in
servers, switches, hubs, etc. that has already been
made in the Internet As It Has Come To Be Known, the
economic incentive to switch to such a system also
runs toward zero.

So, basically, from my perspective, the Internet, as
it is presently configured, is dead. It's WYSIWYG in
the worst possible way. Packet streaming will improve,
and audio (by virtue of its lower bandwidth
constraints) will lead the way, but the rest has quite
a ways to go, and there are a number of physical
constraints that will limit what it can do.

> it seems to
> me that _transmission_ media does not work well,
> either conceptually or
> technically, within this framework.

For the very reasons I noted above.

> Imagine that
> image files had to be
> displayed in an application external to the browser
> unless the webmaster
> had specifically researched how to embed the
> format-specific plug-in into
> the browser - with a different syntax for each image
> format depending on
> the users browser.


As you noted, we are already in that kind of a
situation - if you have video for people to see you
have to think: OK - HOW are they going to see it?

QuickTime? (everywhere, cheap, and well done - but
quality is not the best.)

Real? (Boooo - ugly and the client they provide is
EVIL)

Windows Media? (Quality is great, but it's a product
of the Borg...)

It's not a good situation. The funny thing is, though,
it's NOT a point of OS, it's a problem inherent to IP.

> Well, we put up with this sort of trouble when we
> implement streaming
> within the web, and strangely I dont think we
> complain about it too much.

I do all the time. In fact, it's such a pain in the
arse, I generally don't bother with it.


> Anyway, these are some of the reasons why I dont
> like thinking of
> streaming as a web-based media. It does not belong
> in the web but must
> associate itself with the web by virtue of the fact
> that our use and
> understanding of streaming is very primitive

Actually, I think it's the other way around - I think
it has more to do with the Web Infrastructure's
fundamental protocols (mostly centering around packets
and IP) that are the problem, QUICKLY followed by the
pathetic bandwidth provisioned by contemporary
delivery systems (DSL, cabble, dial-up etc.) 

The crappy quality / service / etc. of streaming and
video on the web/net is a direct result of those two
factors.


> This ties in with the first issue that Felix raises:
> "Does the webcast[sic] itself support a unique
> aesthetic via  streaming
> data reduction, transmission artifacts and recursive
> processing?"

Oddly, I tend to disagree. Think: 1904. There is
recorded sound (cylinders) and there is film (silent
and in black and white) and then asking:

"Does recorded entertainment itself supprt a unique
aesthetic via projection / recording distortions, like
lack of colour and a scratchy tinny sound coming off
these wax cylinders?"

The answer *was* yes, until 25 years later when they
came up with talkies and then film had a scratchy
tinny sound all of its own...

These days, a century later, the answer is something
in between yes and no, as the distortions of film and
video are themselves now seen as aesthetic choices
*within* the creative discipline of cinema.

I would submit that the same is true of webcasting.
Right now it's pretty "nasty" by cinema standards -
blocky chunky images that stutter and jerk in an ugly
intrusive browser - basically where film was with the
nickelodeon.

I submit that this will likely continue to be the case
for quite some time until alternatives to IP and
packet queuing are found.

> "Radio also had an aesthetic influence on music. By
> potentially opening up
> the entire world, it released a fascination for
> hearing global, alien,
> multi-shaped things and stimulated the imagination
> of artists."

Radio and its loud visual child, TV, have also helped
stupefy millions of people into committing and
ignoring amazing atrocities.


> recordings devices (the TEAC 4 track being the most
> used).

One of my faves: the TEAC 3340-S. NICE machine. Here's
a trick I enjoy: take a crapola drum sound and record
it on a 3340, but make sure the input signal is loud,
and the 3340 is saturating the tape. (Use good tape!)
Then sample the results and hack it up in ReCycle,
save it as a ReX file and dump it into Redrum in
Reason. Ultra-In_Your_face drum machine sounds - loud,
punchy and HOT - the analogue distortion on the 3340
preamp circuitry ran up the even numbered harmonics
fairly well - a poor man's Neve or focusrite...


> Normally this (the blocky low-res effect of
streaming video) effect is seen as undesirable.
> However, this kind of
> argument has never made much sense to artists hence
> many artists exploit
> this aesthetic within their work.

To SOME artists. I find it VERY irritating and
extremely undesireable.

I like to USE whatever effects are available. Like
with the 3340 - I don't want to be FORCED to use the
distortions of its pre-amps, I want to CHOOSE those
distortions as a sound source. 

Due to the constraints outlined above, artists (both
the edge of the art videomaker and Steven Spielberg
alike)  are *forced* to these constraints. If I am to
use reduced frame rate and resolution, I want it to be
a Choice, not a Fait Accompli. With the web, it's the
latter.

Eeeek! Gotta run...

HW